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REMARKS 

The present Amendment is in response to the Office Action mailed February 2, 2009. 
Claims 60, 62, 70, and 77 are amended. Claims 60-87 are now pending in view of the above 
amendments. 

Reconsideration of the application is respectfully requested in view of the above 
amendments to the claims and the following remarks. For the Examiner's convenience and 
reference, Applicants' remarks are presented in the order in which the corresponding issues were 
raised in the Office Action. 

Please note that the following remarks are not intended to be an exhaustive enumeration 
of the distinctions between any cited references and the claimed invention. Rather, the 
distinctions identified and discussed below are presented solely by way of example to illustrate 
some of the differences between the claimed invention and the cited references. In addition, 
Applicant requests that the Examiner carefully review any references discussed below to ensure 
that Applicants' understanding and discussion of the references, if any, is consistent with the 
Examiner's understanding. 

Rejection under 35 U.S.C. §112 

Claims 60-87 are rejected under 35 U.S.C. §112, second paragraph, as being indefinite. 
In particular, claims 60, 70, and 77 are rejected as failing to indicate which entity accesses the 
information account. Applicant respectfully traverses the rejection. Applicants respectfully 
assert that claims 60 and 70 are method claims and contain elements recited as actions taken to 
perform the claimed method. It is readily apparent that steps for which no performing entity is 
recited could be performed by any entity and therefore no clarification is needed. 

With respect to claim 77, the preamble clearly recites "A computer readable medium 
having stored thereon computer-executable instructions effective to cause a computer to" 
perform the recited actions. Accordingly, no clarification is needed. 
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Rejection under 35 U.S.C. §103 

The Examiner rejects claims 60-87 under 35 U.S.C. § 103 in view of U.S. Patent 
Publication 2006/0229944 to Walker et al. {Walker) and U.S. Patent No. 6,327,578 to Linehan. 
Applicants respectfully assert 

Walker teaches a system including three entities: a controller, an intermediary or 
merchant, and a user or consumer. Paragraphs 40 and 43. The controller generates a plurality of 
"outcomes" and a corresponding plurality of codes that are used to unlock rewards defined by 
the outcomes. Paragraph 37. The outcomes are provided to users by the controller. Paragraph 
43. The users then obtain the corresponding codes from an intermediary by performing 
"qualifying actions" such as purchasing products from the intermediary. Paragraph 44. The 
users redeem the outcomes by presenting the outcome and code to the controller. Paragraph 
116. In some instances, the user may redeem the outcomes by contacting the intermediary, 
which then contacts the controller for reimbursement. Paragraph 118. A user may have an 
account with the controller that is accessed by the user using authentication information, such as 
a password. Paragraph 117 ("... the user may send a password, voice biometric, photograph, etc., 
to the controller 52 that enables a user to access an account the user has with the controller 52."). 

Linehan teaches a system in which a consumer initiates a transaction by sending "a start 
message over an internet network to a merchant's computer. The merchant's computer then 
replies to the consumer's computer with a merchant message including a wallet initiation 
message.... The wallet initiation message includes a payment amount, an order description, a 
timestamp, and a nonce." Col. 4, Ins. 10-17. The consumer's computer then "sends over the 
internet network some consumer identity and authentication information, such as a userid and 
user password, plus the merchant message, to an issuer gateway operating on behalf of an issuing 
bank. Col. 4, Ins. 19-23. 

The issuer gateway verifies the information and "then pre-authorizes payment by sending 
over the internet network an authorization token, an issuer's digital certificate, the wallet 
initiation message, and a reference value representing the consumer's credit or debit card 
number." Col. 4, Ins. 24-34. The authorization token may be sent "either to the consumer or to 
the merchant to fulfill the order description." The merchant verifies the authorization token and 
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forwards it to an acquiring bank, which then communicates with the issuing bank to transfer the 
funds. Col 4, Ins. 45-64. 

In contrast, claim 60 recites, a method including the elements of "receiving an instruction 
from a consumer via a thin client device to perform a transaction; interacting with a vendor 
server to request the transaction; receiving authorization at a central repository from the thin 
client device for the vendor server to access an information account associated with a consumer 
and maintained in a central data repository and accessible via a distributed network, the 
information account comprising a plurality consumer information elements accessible and 
modifiable by the consumer , and; and accessing the information account to retrieve a payment 
identifier and providing the payment identifier to the vendor server to complete the transaction." 

As noted by the examiner Walker fails to disclose "receiving authorization at a central 
repository from the thin client device for the vendor server to access an information account 
associated with a consumer and maintained in a central data repository and accessible via a 
distributed network, the information account comprising a plurality of accessible and modifiable 
consumer information elements accessible and modifiable by the consumer; and accessing the 
information account to retrieve a payment identifier and providing the payment identifier to the 
vendor server to complete the transaction" as formerly recited in claim 60. 

Applicant respectfully asserts that Linehan fails to disclose " receiving authorization at a 
central repository from the thin client device for the vendor server to access an information 
account associated with a consumer and maintained in a central data repository and accessible 
via a distributed network, the information account comprising a plurality of consumer 
information elements accessible and modifiable by the consumer , and accessing the information 
account to retrieve a payment identifier and providing the payment identifier to the vendor server 
to complete the transaction," as currently recited in claim 60. 

The Examiner has cited Col. 4, Ins. 10-64 of Linehan as teaching these elements. 
Applicant respectfully asserts that the cited passage fails to teach or suggest all of the elements 
not found in Walker. 

The only consumer information provided in Linehan is "a reference value representing 
the consumer's credit or debit card number." Col. 4, Ins. 32-34. However, this reference number 
is not part of an "information account comprising a plurality of consumer information elements 
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accessible and modifiable by the consumer," as recited in claim 60. The reference number "is an 
authorization number allocated uniquely by the issuer gateway for each authorization . This 
authorization number is passed by the acquirer gateway back to the issuing bank in the capture 
message. The issuing bank maintains a database mapping authorization numbers to card 
numbers." Col. 10, Ins. 63-67. 

It is therefore apparent that the reference number is nothing but a temporary identifier 
mapped to the user's credit card number. Linehan contains no teaching, suggestion, or any 
apparent reason for the consumer to access or modify the "database mapping authorization 
numbers to card numbers." Linehan teaches against such functionality since the purpose of the 
database is to avoid disclosing the consumers' actual credit card number. See, e.g., Col. 10, Ins. 
59-61 ("A stolen alias card number has no use..."). Enabling a consumer to access and modify 
the database would make the reference number less secure. 

With respect to claim 62, Linehan and Walker, whether alone or in combination, fail to 
teach or suggest the elements of "retrieving consumer preferences for the transaction from the 
information account; and wherein interacting with the vendor server to request the transaction 
comprises communicating the consumer preferences to the vendor server." 

Walker has been cited as teaching the collection of profile and demographic data. 
However, the data collected by Walker is not "retrieved] . . . from the information account" as 
recited in claim 62, where the information account is as recited in claim 60. 

Walker teaches that "all users having or meeting certain demographic profile may be 
eligible to receive or download one or more outcomes." Paragraph 99; See also Paragraph 133. 
Walker further teaches that a "user might have to fill out a survey... releasing private 
information such as the user's demographic data or profile" Paragraph 133. However, a user's 
demographic is not equivalent to a consumer's preferences for a given transaction. In particular, 
it does not dictate details of a transaction involving the exchange of "outcomes" and "unlock 
codes" as taught by Walker. 

Paragraph 104 and Figure 13 have been cited in response to arguments previously 

submitted with respect to claim 62. Paragaph 104 recites: 

"During the step 106, the controller 52 provides one or more of the unlock codes 
generated during the step 102 to one or more intermediaries or intermediary 
devices. Like outcomes, unlock codes may carry or be associated with 
11 
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information or instructions. In some embodiments, an intermediary may have to 
provide payment prior to or after receiving a code. Also an intermediary, or a 
third party on behalf of the intermediary, may have to request to receive codes or 
agree to receive codes." 

It is clear that the unlock codes are information generated by the controller and then provided to 
the intermediary. There is no indication that the unlock codes are a preference of the 
intermediary stored with the controller. There is further no indication that the unlock codes are 
"preferences for [a] transaction." The data structure of Figure 13 fails to remedy this deficiency. 
Walker teaches that "[t]he user device 54 may include a user outcome database 760 to store 
information and data regarding outcomes received by the user device." Paragraph 194. It is 
therefore apparent that this data structure stores data regarding transactions and does not contain 
any data that could be characterized as a "preference" "outcomes." Furthermore, the data 
structure of Figure 13 is stored on the user device and therefore isn't stored in an information 
account as recited in claim 60 and is further not accessed as recited in claim 62. 

Linehan teaches only database "mapping authorization numbers to card numbers," which 
in no way relates to the elements of claims 62. Linehan therefore fails to remedy the deficiencies 
of Walker. 

With respect to claim 70, for at least the reasons noted above with respect to claim 60, 
Walker and Linehan fail to teach or suggest a method including the elements of "maintaining an 
information account in a central data depository accessible via a distributed network, the 
information account comprising a plurality of consumer information elements accessible and 
modifiable by the consumer , receiving an instruction from a thin client device at a vendor server 
to perform a transaction; receiving authorization at the central repository from the thin client 
device for the vendor server to access the information account; and accessing the information 
account to retrieve a payment identifier and providing the payment identifier to the vendor server 
to complete the transaction; and processing a payment using the payment identifier. 

With respect to claim 72, for at least the reasons noted above with respect to claim 62, 
Walker and Linehan fail to teach or suggest a method including the elements of "retrieving 
consumer preferences for the transaction from the information account; and wherein interacting 
with the vendor server to request the transaction on behalf of the consumer comprises 
communicating the consumer preferences to the vendor server." 
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With respect to claim 77, for at least the reasons noted above with respect to claim 60, 
Walker and Linehan fail to teach or suggest "computer-executable instructions effective to cause 
a computer to: receive an instruction from the consumer via a thin client device to perform a 
transaction; receive authorization at a central repository from the thin client device for the vendor 
server to access an information account associated with a consumer and maintained in the 
central data repository and accessible via a distributed network, the information account 
comprising a plurality of elements accessible and modifiable by the consumer , interact with a 
vendor server to request the transaction; and access the information account to retrieve a 
payment identifier and provide the payment identifier to the vendor server to complete the 
transaction." 

With respect to claim 80, for at least the reasons noted above with respect to claim 62, 
Walker and Linehan fail to teach or suggest "computer-executable instructions . . . effective to 
cause the computer to retrieve consumer preferences for the transaction from the information 
account." 

CONCLUSION 

In view of the foregoing, Applicants believe the claims as amended are in allowable 
form. In the event that the Examiner finds remaining impediment to a prompt allowance of this 
application that may be clarified through a telephone interview, or which may be overcome by an 
Examiner's Amendment, the Examiner is requested to contact the undersigned attorney. 

Dated this 1st day of April, 2009 

Respectfully submitted, 

/R. Burns Israelsen/ Reg. No. 42685 

R. BURNS ISRAELSEN 
Attorney for Applicant 
Registration No. 42,685 
Customer No. 022913 
Telephone No. (801) 533-9800 
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